…ions.

The "Install Samtools" step was running `apt-get upgrade` with no package
list, which upgrades every package on the runner — including the firefox
transitional `.deb` that bootstraps the Firefox snap. When the snap store
is unreachable (an intermittent failure mode), the upgrade blocks for ~50
minutes and then fails the job, even though htsjdk needs nothing from
firefox. Drop the upgrade entirely; the only packages this script needs
are the three -dev libs already installed explicitly.

Bump samtools to 1.23.1 and cache the built binary keyed on version + OS,
so subsequent runs skip the ~3-5 min compile. Move the install prefix to
/usr/local since /usr is reserved for the distro package manager and is
the conventional location for locally-built software.

Bump actions/checkout and actions/setup-java to v4 (v3 ran on Node 16,
which is end-of-life on the Actions runtime), and switch the JDK
distribution from `adopt` to its current name `temurin`.

The previous setup relied on actions/setup-java's `cache: gradle`
option, which caches `~/.gradle/caches` (resolved dependencies) but
NOT `~/.gradle/wrapper/dists/`. Every CI run was therefore
re-downloading the ~150 MB Gradle distribution zip on top of its own
cold dependency resolution.

Gradle publishes an official action that handles both: the wrapper
distribution and the dependency cache, with smarter cache-key
heuristics than setup-java's basic option. Drop `cache: gradle` from
setup-java and add `gradle/actions/setup-gradle@v4` after it in each
job.

We've been seeing intermittent `OutOfMemoryError: Java heap space` in CI
test runs. With TestNG `parallel = "classes"` running availableProcessors()
threads in a single JVM, peak heap demand scales with concurrency, and 12G
was right at the edge on the 16G GitHub runner.

Bump test JVM `maxHeapSize` to 14G. To make that safe, pin the gradle
daemon's own footprint via gradle.properties (-Xmx512m + Metaspace cap)
so it doesn't compete for the same physical RAM. Combined budget on a
16G runner: ~14G test heap + ~1G test non-heap + ~1G daemon + OS
headroom.

The previous test asserted a substring match against a hardcoded version
string, which broke any time CI bumped samtools (just happened: 1.21 →
1.23.1). htsjdk only cares that the local samtools is at least the
version the tests were written against, not that it's exactly that
version, so do a numeric semver comparison instead.

Adds two small package-private helpers to SamtoolsTestUtils:
- parseSamtoolsVersion(String) extracts the version from `samtools
  --version` output via a single regex.
- compareVersions(a, b) compares two dotted-numeric version strings
  component-by-component, treating missing trailing components as zero.

The version test now parses the running samtools version and asserts
it is >= minimumSamtoolsVersion (renamed from expectedSamtoolsVersion
to reflect the new semantics, bumped to 1.23.1 to match the version
CI installs).

Adds small unit tests for the parser and comparator covering typical
output, two-component versions, missing version line, equality with
implicit trailing zero, ordering across major/minor/patch, and the
1.10 vs 1.9 numeric-not-lexical case.